Proposed changes

Fixes #1075
Bug: The bug happens when converting np.array(1., dtype=ml_dtypes.bfloat16) and np.array([1.], dtype=ml_dtypes.bfloat16) to mx.array(x). For the former case, it'll silently be caught as a std::complex as part of ArrayInitType and get converted as such (see related issue for code). For the latter, it'll be interpreted as an ArrayLike, not be able to make the conversion to mx.array() and raise a ValueError.
The Fix: We need to catch this case before it gets filtered by ArrayInitType. I made the array.__init__ more generic to catch this and checked the dtype to match bfloat16, then manually construct the array. Otherwise, we fallback to the original ArrayInitType case.
Note: bfloat16, is the only current ml_dtype that mlx supports.
Verification: Verified locally (macOS 26.2, MLX 0.30.7, Apple M2) with the additional test case I provided. If this is run from main, it raises the bug mentioned above:

    @unittest.skipIf(not has_ml_dtypes, "requires ml_dtypes")
    def test_conversion_ml_dtypes(self):
        x_scalar = np.array(1.5, dtype=ml_dtypes.bfloat16)
        a_scalar = mx.array(x_scalar)
>       self.assertEqual(a_scalar.dtype, mx.bfloat16)
E       AssertionError: mlx.core.complex64 != mlx.core.bfloat16

Checklist

Put an x in the boxes that apply.

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works
• I have updated the necessary documentation (if needed)